DMV — Synthèse d'architecture : le Ranking Engine et l'organisation du Context Engine
Introduction
Ce document consolide l'ensemble des réflexions menées à travers plusieurs documents et échanges successifs. Il ne remplace pas les documents précédents (vision, principes de pertinence, pipeline de décision) — il les organise, tranche les points restés ouverts, et ajoute la pièce qui manquait depuis le début : le mécanisme concret de classement, appelé ici Ranking Engine.
Il reste un document métier. Aucune technologie n'y est mentionnée.
1. Les trois surfaces du Context Engine
La réflexion a longtemps traité DMV comme un moteur unique. Il apparaît en réalité que le Context Engine sert trois usages distincts, qui partagent une base commune (pipeline, filtrage, exclusion des contenus invalides) mais qui se déclenchent différemment et ne composent pas leurs résultats de la même façon.
1.1 Le MurVille (mur public territorial)
- Contexte maîtrisé : une commune, un flux public.
- Publications empilées par date, filtrées par validité.
- Ce sujet est considéré comme réglé et n'est pas l'objet de ce document.
1.2 Le mur personnel (privé, mode passif)
- Alimenté sans requête explicite de l'utilisateur.
- Doit refléter ce qui le caractérise : ses relations, ses centres d'intérêt, sa géographie.
- C'est le sujet principal de ce document (sections 2 à 5).
1.3 La recherche mixte (mode actif, intention explicite)
- Déclenchée par une requête en langage naturel, potentiellement multi-intentions (ex : logement + activités + sorties + événements).
- Décomposée en sous-recherches spécialisées par type d'objet, chacune avec ses propres filtres durs et son propre classement local.
- La composition du résultat final suit directement la structure des intentions détectées dans la requête — pas de calcul de densité territoriale nécessaire ici.
- Un LLM a un rôle légitime à ce niveau : extraction d'intention et structuration de la requête, jamais pour le ranking final, qui reste déterministe.
2. Le mur personnel : deux flux de nature différente
Le mur personnel n'est pas un flux unique filtré par plusieurs critères combinés. Ce sont deux flux indépendants, fusionnés ensuite dans une seule liste, mais dont les règles d'inclusion n'ont rien à voir.
2.1 Flux relationnel
- Alimenté par les acteurs explicitement suivis par l'utilisateur.
- Inconditionnel : aucun filtre géographique ne s'applique. Un acteur suivi dans une ville jamais visitée par ailleurs reste dans le mur, parce qu'il caractérise l'utilisateur.
- Principe fondateur : ce qui définit l'utilisateur (ses relations explicites) prime toujours sur ce qui décrit son environnement (sa position, ses villes).
2.2 Flux territorial (découverte)
- Alimenté par la géographie active de l'utilisateur : ville favorite (résidence), ville GPS (position actuelle), villes suivies (famille, vacances, attaches occasionnelles).
- Sert la sérendipité : sans lui, l'utilisateur ne verrait jamais rien de nouveau, juste ce qu'il suit déjà.
- Règle d'inclusion asymétrique selon le rôle de la ville :
- Ville favorite et ville GPS : la géographie seule suffit à inclure une information.
- Villes suivies (non favorite, non GPS) : la géographie seule ne suffit pas. Il faut en plus au moins un signal d'affinité (catégorie suivie, acteur suivi même non localisé dans cette ville, importance intrinsèque de l'information).
2.3 Fusion et étiquetage
Les deux flux sont fusionnés dans une seule liste, mais chaque élément conserve un tag d'origine et de justification (ex : « pertinent car acteur suivi », « pertinent car ville favorite + fraîcheur », « pertinent car catégorie voyage suivie »). Ceci répond à un double besoin : transparence pour l'utilisateur, et auditabilité pour la conception (pas de score caché).
3. La portée géographique : abandonner le rayon fixe
Le rayon unique paramétré par utilisateur ne fonctionne pas, parce qu'il applique la même contrainte spatiale à des informations dont l'importance n'a rien à voir avec la distance. Deux exemples extrêmes l'illustrent :
- Un repas associatif à 5 km ne doit pas apparaître, malgré la faible distance, en l'absence de tout signal d'affinité.
- Un concert d'envergure nationale à 20 km doit apparaître, malgré la distance, parce que son importance intrinsèque dépasse le rayon habituel.
3.1 Principe retenu
La portée n'est jamais une propriété fixe de l'utilisateur seul. C'est une fonction de trois éléments combinés :
- Catégorie de l'information (alerte, événement, publication municipale, commerce…)
- Affinité de l'utilisateur pour cette catégorie (dérivée des acteurs suivis, des centres d'intérêt déclarés, des « ça m'intéresse »)
- Envergure intrinsèque de l'information (locale / intercommunale / départementale / nationale)
3.2 Portée par catégorie (règle de base, avant affinité)
- Alertes de sécurité / criticité : portée par rayon géographique réel (km), indépendante du découpage administratif. Une alerte incendie se propage selon un rayon de danger réel, pas selon les limites de la commune.
- Informations municipales officielles : portée naturellement communale.
- Événements / vie associative / loisirs : portée par rayon + affinité déclarée obligatoire au-delà du rayon de base.
- Commerces / annonces : portée resserrée par défaut, élargie seulement par un signal d'intérêt fort.
3.3 Envergure : comment la connaître sans imposer de saisie au producteur
Contrainte UX-first : on ne demande pas au producteur de classifier lui-même l'envergure de sa publication. On la déduit de signaux structurels déjà disponibles :
- Le type d'acteur (antenne locale isolée vs acteur rattaché à un réseau/une fédération/une franchise connue).
- Le nombre de communes distinctes relayant la même information.
- Le volume agrégé et anonyme d'intérêt (« ça m'intéresse » toutes villes confondues) sur cet objet précis — signal sur l'objet, pas sur un comportement individuel, donc compatible avec les exigences de déterminisme de la V1.
Ce point reste ouvert et mérite d'être creusé en priorité basse (voir section 6).
3.4 Point explicitement écarté
Toute forme de priorité liée à une contrainte commerciale (prix, places limitées payantes) est à proscrire du ranking : cela reviendrait à favoriser artificiellement un producteur de contenu, ce que les principes fondateurs interdisent. Une contrainte de capacité réelle (places limitées, gratuites ou payantes) pourrait légitimement justifier un facteur d'urgence, mais ce facteur n'est pas retenu pour la V1 (dépendance technique trop lourde : nécessite un flux temps réel de taux de remplissage).
4. Le Ranking Engine
4.1 Ce que le Ranking Engine n'est pas
- Ce n'est pas un score global unique à poids fixes mélangeant tous les facteurs dans une seule formule opaque (rejeté depuis le début : illisible, impossible à auditer, effets de bord imprévisibles).
- Ce n'est pas non plus un empilement de règles IF-THEN imbriquées (rejeté : devient une usine à gaz dès que les cas particuliers s'accumulent).
4.2 Ce que le Ranking Engine est
Une combinaison de facteurs nommés, indépendants, chacun une petite fonction simple et auditable séparément. Chaque facteur peut être expliqué isolément à un utilisateur qui demanderait « pourquoi je vois ceci en premier ? ».
4.3 Les facteurs identifiés
| Facteur | Nature | Rôle |
|---|---|---|
| Criticité / priorité intrinsèque | État temporaire, court-circuite le reste | Sécurité, urgence — toujours en tête tant que l'état est actif |
| Relation directe (acteur suivi) | Binaire | Inclusion inconditionnelle, sans filtre géographique |
| Affinité catégorielle | Dérivée (acteurs suivis + centres d'intérêt + seuil sur « ça m'intéresse ») | Élargit la portée territoriale au-delà du rayon de base |
| Proximité géographique pondérée | Rôle de la ville : favorite > GPS > suivie | Filtre d'entrée du flux territorial |
| Envergure intrinsèque | Déduite de signaux structurels (voir 3.3) | Permet de dépasser le rayon habituel |
| Fraîcheur de publication | Décroissance depuis la date de parution | Pic à la publication, puis décroissance |
| Proximité temporelle à l'événement | Courbe en cloche centrée sur la date d'occurrence | Fait remonter un événement à l'approche de sa date |
4.4 Le cas des informations datées : deux courbes superposées
Une information avec une date d'occurrence future (ex : une fête de village) combine deux dynamiques temporelles distinctes, à ne pas confondre :
- Fraîcheur de publication : pic au moment de la parution, décroissance ensuite — répond à « les habitants sont-ils déjà informés ? ».
- Proximité temporelle à l'événement : courbe en cloche centrée sur la date cible — répond à « dois-je m'organiser maintenant ? ».
Le résultat combiné produit une courbe à deux bosses (pic à la publication, creux intermédiaire, second pic à l'approche de l'événement). Les deux courbes sont calculées indépendamment ; leur combinaison (somme ou maximum) reste à trancher empiriquement une fois des données réelles disponibles.
4.5 Ce qui reste en amont et ne change pas
Le pipeline déjà posé (Chargement → Filtrage → Validation → Classification → Priorisation) reste la base indispensable. Le Ranking Engine ne s'applique qu'aux candidats déjà valides et filtrés — il ne remplace aucune étape existante, il vient combler ce qui, dans les documents précédents, était nommé tour à tour « pertinence contextuelle », « classement », « composition », « densité utile », sans jamais être formalisé.
5. Principes transverses à ne pas perdre de vue
- Déterminisme : mêmes données, mêmes règles → même résultat. Chaque facteur du Ranking Engine est une fonction pure, testable isolément.
- Explicabilité : chaque publication porte un tag de justification (section 2.3). Aucun facteur ne doit rester une boîte noire.
- Neutralité vis-à-vis des producteurs : aucun facteur ne doit favoriser une publication pour des raisons commerciales (section 3.4).
- Pas de logique d'engagement : le mur a une fin visible ; il ne cherche pas à maximiser le temps passé, le nombre d'ouvertures ou le scroll. L'effet d'anticipation recherché (« l'info avant qu'on sache qu'on en a besoin ») est un résultat du bon ranking déclaratif, pas une fonctionnalité de prédiction comportementale séparée.
- Séparation V1 / Adaptive Engine : tous les facteurs retenus pour la V1 sont déclaratifs (suivi explicite, intérêt marqué avec seuil documenté, géographie choisie). Aucun apprentissage comportemental continu n'entre dans le Ranking Engine V1. Toute évolution vers une personnalisation apprise reste un sujet distinct, à traiter consciemment plus tard.
6. Prochaines étapes
- Trancher les points encore ouverts :
- Priorité de principe du flux relationnel sur le flux territorial dans la liste fusionnée, ou tri unique par score une fois réunis ?
- Mode de combinaison des deux courbes temporelles (somme ou maximum) — à tester empiriquement.
- Définir un barème de poids initial pour les facteurs du Ranking Engine, ajustable empiriquement à l'usage.
- Auditer l'existant technique : identifier ce qui, dans le feed actuel, correspond déjà à un ou plusieurs facteurs, et ce qui manque entièrement (courbe temporelle, envergure, séparation des deux flux).
- Approfondir le calcul d'envergure (section 3.3), en priorité basse — ce n'est pas bloquant pour une première version du Ranking Engine.
- Confronter l'architecture au point de vue d'un maire ou d'un élu local, en parallèle du reste — angle mort identifié, absent des trois personas déjà couverts (habitant, chef d'entreprise, président d'association).
- Implémenter chaque facteur comme une fonction pure et testable indépendamment, pour préserver le déterminisme dès la mise en œuvre technique.s